Computer applications, and relatively large-scale computer applications in particular, typically are constructed according to an architectural partitioning design that conceptually divides the application into logical groupings. As may be appreciated, such groupings serve to help in understanding the application in broad terms. As an example of such architectural partitioning, it may be the case that an application is divided into groupings, partitions, or areas of focus that include a user interface (UI), application logic, data storage, and the like.
Notably, an architectural partitioning design of a particular application may specify not only a number of partitions, but may also specify whether and how components of the application in each specified partition may refer to components of the application in other specified partitions. As may be appreciated, a reference within a first component to another, second component creates a dependency in the first component to the second component. As may also be appreciated, such references or dependencies may be useful and even necessary, but also may have the effect of tying together the components of the application in an unwanted and/or unwise manner. Thus, an architectural partitioning design for the application may specify that the first component if in a first partition can refer to the second component if in a second partition, but not to the second component if in a third partition.
As should be understood, by employing architectural partitioning according to logical groupings, and particularly in modular systems, adherence to the defined groupings and allowed dependencies allows for configuration agility. For example, and as may be appreciated, if application logic in an application is partitioned to be separate from the user interface in such an application, components that are employed to provide the application logic may more readily be employed in another application that may perhaps be similar in nature but that has a different user interface. Thus, and as a dependency rule, a component in an application logic partition should not depend on a component from a user interface partition for the reason that such a dependency would prevent the application logic from being employed with another user interface.
The theory and use of architectural partitioning is well-established with regard to a computer application. However, it is also well-established that given the opportunity to do so, a developer developing one or more components for the computer application may violate the architectural partitioning defined for the application, either intentionally or unintentionally. That is, applications, and especially the aforementioned relatively large-scale computer applications, tend to fall out of accordance with and diverge from the architectural partitioning that has been defined therefor.
In one typical example of such a divergence, an architectural partitioning design of a particular application may specify a rule that components in a first partition may refer to/depend on components in a second partition, but not components in a third partition. However, despite such a dependency rule, a developer developing the application in fact either intentionally or unintentionally violates same by developing a component in the first partition that refers to/depends on a component in a third partition. Put simply, placing a reference from one component to another is typically a simple thing to do, and no safeguards presently exist to inform the developer that a particular reference may violate a dependency rule and create a divergence.
In general, divergences occur primarily for the reason that the architecture of an application is typically designed and maintained separately from the application itself. Put simply, such architecture is not typically embodied in source code or any other memorialized form that could be used to actually build the application. Moreover, it is oftentimes the case that the architecture application is defined by one person or group of people and developed by another person or group of people. Thus, if a divergence occurs between an application as developed and the architecture defined for the application, no method or mechanism exists to identify the divergence, or to halt building of an application that has diverged from the architecture defined for such application.
Accordingly, a need exists for a method and mechanism that enforces the architectural partitioning defined for an application. In particular, a need exists for a method and mechanism that in fact identifies a divergence between an application as developed and the architecture defined for the application. Likewise, a need exists for a method and mechanism for halting building of an application that has diverged from the architecture defined for such application.